Prbatero/feat/data publishing local - #122

…lease

Bucket A (additive) from the -sol audit split, Phase 1 (Local only; no PC):
- core/publishing/: base ABC + registry (PC lazy-loaded, disabled by default),
  repository (per-dataset docs + optimistic concurrency), source (eligibility +
  artifact resolution), lease (blob-lease coordinator), local_provider (immutable
  copy to published/{datasetId}/).
- models/publishing.py; processors/publishing.py + assessment.py.
- Additive infra: config publishing block + PUBLISHED_DATASET type + publish
  queue; data-layer load_bounded/load_page/update_locked; artifact-storage
  copy/scoped-download/etag/size/exists/delete_prefix; blob.py max_bytes.
- hastefuncqueues publish trigger.
- Phase-1 unit tests (registry/repository/source/local_provider/lease): 45 pass.

Excludes Bucket B: reverted the high-risk load_all/load_all_from_partition
rewrite to main's versions; endpoint hardening + DTOs left for a separate
-hardening PR. See spec/features/data-publishing/sol-classification.md.

… deploy paths

The Config drift check failed with:

  Dead application settings (set but never read):
    PUBLISHING_ENABLED  (set by infra/modules/functions.bicep, read by no code)

That was a false positive. PUBLISHING_ENABLED is read in hastegeo.core.config
via _get_bool_env("PUBLISHING_ENABLED", False), but check_env_drift.py's AST
scanner only recognized os.getenv, os.environ.get, and os.environ[...]. The new
typed wrappers _get_bool_env and _get_bounded_int_env were invisible to it, so
no reader was found and the setting looked dead.

The blind spot covered five variables, not one: PC_PROVIDER_ENABLED,
PUBLISH_MAX_TOTAL_BYTES, PUBLISHED_DOWNLOAD_SAS_MINUTES and PC_VERIFY_ATTEMPTS
are read through the same helpers and were equally unseen. They simply did not
error because no deploy path emits them yet.

Teach the scanner to treat _get_*_env(NAME, ...) calls as reads. The wrappers
supply their own default in the signature, so such a read counts as optional
even when the call site passes no default.

Separately, fix the real drift the check could not see: PUBLISHING_ENABLED was
emitted by functions.bicep but not by deploy_apps.sh, so environments deployed
through the GitHub Actions path would never receive it and would silently fall
back to false while Bicep-provisioned environments got the flag. Emit it from
deploy_apps.sh too, defaulting off to match the Bicep param, and wire it
through deploy-apps.yml as a GitHub Environment variable (non-sensitive feature
flag, same treatment as VITE_SHOW_FOOTER).

…s, polling, privacy

Resolve Copilot review findings on the publishing feature:

- Embedding eligibility: source resolver gated on inferenceStatus, but embedding
  models signal completion via `status`. Gate on `status` for modelType
  "embedding", else inferenceStatus — otherwise every embedding publish was
  rejected before the embedding artifact logic ran.
- Publish action on EmbeddingModelRow used inferenceStatus (never set for
  embeddings); use the already-computed isProcessed.
- Owner detection: populate appParams.identityId from the SWA principal object id
  so it matches PublishedDataset.publishedByUser; previously identityId was never
  assigned, so non-admin publishers were never recognized as owners and
  Retry/Unpublish were hidden.
- Publish dialog reported "Publishing started" on a 409 conflict (apiPut returns
  the status rather than throwing); surface the conflict as an error instead.
- Published Datasets polling captured a stale query (page/filters/search/sort);
  drive the interval through a ref to the latest fetch and pause it while the
  search is not ready.
- Persist the publisher email/login rather than the display name
  (PublishedDataset.publishedByName) — display names resolve from Entra at read.
- Remove aria-modal=false from the publish dialog (it is a focus-trapping modal).
- Provider registry: a Planetary Computer target is "configured" once the
  GeoCatalog URL is set; do not also require an ingestion source (needed only for
  private containers), so the public-container mode is configurable.

Publishing adds the queues app's first timer trigger
(ReconcilePublishingOperations), which acquires a host-scoped Singleton lock. A
colliding auto-generated host id (long app name / shared storage / deployment
slots) then surfaces as "Unable to acquire Singleton lock" and NoScriptHost,
leaving the app unhealthy. Document setting a unique AzureFunctionsWebHost__hostId
per app/slot in the rollout operator notes. Applies to Local and PC (the timer
ships with the Local feature).

The section fetched its first page with fetchDatasets(false), so no loading
indicator showed and the page rendered blank (the component returns null while
items === null) until data arrived — noticeable on slower cloud loads. Trigger
the shared full-page loading overlay on the first load (items === null), matching
the Model Catalog pattern; later filter/search/sort/page changes still refetch
silently so the overlay doesn't flash on every interaction.

…aining submit)

The initial publishing commit moved the module-level
`from hastegeo.core.processors.train import TrainPreprocessor` import into a
local import inside PutCancelModelQueueMessage, but PutRunModelQueueMessage (and
the retrain path) still reference TrainPreprocessor at module scope. That raised
an unhandled NameError on every training submit, surfaced to the client as a 500
from PutRunModelQueueMessage. Restore the top-level import and drop the now
redundant local one.